ITM305 Final Exam - System Analysis and Design

ITM305 Final Exam - System Analysis and Design (Toronto Metropolitan University)

• System Sequence Diagram (SSD): Shows interactions between an actor and the system for a use-case scenario. The system is visualized as a black box. Initiating actors and external systems are identified. The messages exchanged, and their sequence within the system, are detailed. Special cases for sequence diagrams illustrate object use within the system, highlighting inputs and outputs for a use case. Actor, system, and object lifelines are part of the diagram. Messages show content and structures of system inputs and outputs. Formatted messages in SSD follow UML format (lowercase letters, no spaces, using commas to separate parameters. Empty parentheses are used if no parameters needed)

• Message Formats in SSD: Message names are followed by parameters. Names start with lowercase letters. Compound words are combined with uppercase letters as delimiters. Parameters are separated by commas. If no parameters exist, empty parentheses are used. True/False conditions are indicated by [true/false condition]. Return values, if any, are included with :=. An asterisk (*) indicates repetition or looping. Brackets [] are used for true/false conditions. The message-name (verb-noun description) and a parameter-list (with parentheses, if applicable) denote the service and passed data. Return values (denoted by :=) return data between source and destination objects.

• System Events and System Operations: System operations are public, black-box functions offered by the system. These are triggered by external inputs/system events, initiated by actors.

• Extending and Integrating Requirements Models: Includes use case diagrams, use case descriptions, activity diagrams, system sequence diagrams (SSDs), and domain class diagrams to illustrate use case realizations. Domain classes, using models, are part of the diagram.

• Steps of Object-Oriented Design: Object-oriented design methods identify classes, their methods, and messages to complete a use case. The primary driving component in the design methodology is use cases.

• Design Class Diagrams: Stereotype descriptions use guillemots (<< >>). Persistent classes persist after shut downs (e.g., data). Entity classes denote problem domain classes. Boundary classes represent system boundaries (input/output). Controller classes control communication between boundary and entity classes. Data access classes manage database interaction. A class's attributes have visibility (e.g. +public, −private).

• Fundamental Design Principles (Week 9): Object responsibility, knowing and doing, separation of concerns, and protection from variations are core principles. Objects are fundamental to system processing. Segregation by class into groups or packages improves overall organization. Parts of a system less likely to change are separated to protect from major variations.

• Quantitative Measurement of Coupling (Week 9): Measures how tightly related classes are linked, ranging from tightly to loosely coupled. Fewer associations or messages reduce coupling, which is the desired outcome.

• Cohesion (Week 9): Measures internal unity of purpose in a class. High cohesion implies cohesive responsibilities (e.g., all customer-related responsibilities are in one class). Conversely, low cohesion suggests broad or mismatched responsibilities. Higher is better to increase system organization.

• Encapsulation (Week 9): Bundles data with methods operating on that data within a single unit. Objects encapsulate data, using methods to hide data members/methods, improving system robustness. This decreases interdependence between system components.

• Inheritance (Week 9): A mechanism to derive class attributes and methods from a parent (super) class into child (subsidiary) classes. Inheritance creates a hierarchy, inheriting from parents. It avoids redundant code. Parent/superclass attributes/methods don't need to be redefined in child/subclasses.

• Indirection (Week 9): Introduces an intermediate class between interacting entities. Improves system decoupling, but still links them. Security can also be supported to handle messages and maintain robustness. Example including a controller class between UI and problem domain classes.

• Polymorphism (Week 9): Allows same-named methods with differing parameters in the class. Reduces code, improving the flexibility and extensibility of class systems within a given class, using same names with different parameters which provides different operations or implementations for each use.

• Use Case Controller (Week 9): Acts as a switchboard between user interfaces and domain layers. Reduces coupling between layers, improves organization and maintains a central location for directing communications between system layers. It can be created for a use case or group of related use cases (e.g., artifact).

• Understanding Sequence Diagrams (Week 10): Sequence diagrams clarify interactions between system objects and actors, using lifelines, activations, and messages. The dashed lines under objects are lifelines, which are origin/destination points for messages. Activation (vertical box on the lifeline) indicates actions. Messages (arrows) identify exchanges and return values.

• OOD with Sequence Diagrams (Week 10): Guides use case selection, creation of initial Data Class Diagrams (DCDs) and extending the DCDs with further messages (add input messages).

• Guidelines for Sequence Diagrams (Week 10): Details the format of the input use case messages, the messages, determining origin and destination objects, elaborating messages. Fleshing out each message with true/false, parameters, and return values.

• Assumptions for Sequence Diagrams (Week 10): Assumes a perfect technology, no logon or tech issues, and no exceptions are handled which maintains a simplistic view of the system.

• Fundamental Design Principles (Week 10): Emphasizes Protection from Variations: Separating parts of a system that are likely to change from those that remain stable (e.g., UI vs application logic).

• Multilayer Sequence Diagrams (Week 10): Incorporates view layers and data layers for input handling and data access. View layer manages input screens, sends messages to the data layer, which accesses relevant data systems.

• Data Layer (Week 10): Handles persistent object reading and updating, including reading/writing data to systems. Instantiate objects and send messages managing data persistence. Methods provide data access and object instantiation.

• Package Diagrams (Week 10): Categorize, group, and visually represent classes or subsystems within the system. Package usage creates a method of classifying components/subsystems in the system. A dependency relationship, indicated by dashed lines, denotes a component/module dependency.

• Implementation Issues Three Layer Design (Week 10): Lists Responsibilities of the View Layer for handling user interactions and reports, displaying data as well as receiving and validating user input.

• Agile Development (Week 11): A philosophy and guidelines, emphasizing responding to change and customer collaboration over plans and documentation in a rapidly changing environment. Chaordic projects, as a guide, refer to chaotic yet ordered projects.

• Agile Values (Week 11): Emphasizes customer collaboration and working software, not comprehensive documentation or sticking to strict plans. This leads to flexibility, adapting to changing environments.

• Agile Principles (Week 11): Describes responsive project design and development values, in contrast to fixed plans, using principles (build only necessary, next effort as secondary goal), minimizing modeling efforts to achieve forward movement, adapting to change, which can reversed if necessary. All build on the fundamentals of understanding and communicating requirements during the software development cycle.

• SCRUM (Week 11): Combining principles of rugby and agility in software development, using time-boxed projects as important methodologies. Scrum methods are used for project management.

• Scrum Sprint (Week 12): Project implementation, time-boxed, part of the system.

• Product Backlog (Week 12): A prioritized list of user requirements for the system, to be followed in the project management cycle.

• Product Owner (Week 12): The client stakeholder who controls the product backlog, as part of the project management cycle.

• Scrum Master (Week 12): The project manager who leads and supports the project team, as part of the project management lifecycle.

• Domain Layer Classes (Week 12): Classes related to the problem being solved. They carry out the business logic and are the core of the system. This can include creating and managing data storage, such as data persistence (database).

• Data Access Layer Classes (Week 12): Responsible for data interaction with the database. Functions include establishing database connections, executing SQL statements on databases, and converting database result-set information into domain objects.

• Domain Layer and Data Access Layer Responsibilities (Week 12): Details specific responsibilities of the Domain (business logic) and Data Access layers to be considered.

• Start and Shutdown (Week 12): The initiation and completion of system operations and activities.

Test your knowledge on System Analysis and Design concepts with a focus on System Sequence Diagrams (SSD). This quiz covers key topics like interactions, message formats, and UML conventions that are critical for understanding system use-case scenarios. Perfect for Toronto Metropolitan University students preparing for their final exam.