INF390 ANÁLISIS Y DISEÑO DE SOFTWARE TP Nro 3

Summary

Ana Carolina Ferreira explains the expectations for Practical Work 3 (TP3) in the Analysis and Design of Software course. TP3 is part of an iterative, incremental project that runs from TP1 through TP4. Students should build on earlier work, apply instructors’ corrections, and add the new TP3 artifacts.

The goal is to analyze and design one small, specific software functionality in a complete and consistent way, rather than model an entire system.

Main Submission Expectations

Integrate and revise previous work

Carry forward the system description, requirements, use-case derivation and table, and use-case diagram from earlier assignments. Apply the instructors’ feedback as you revise them.

Model use cases

• Include a general use-case diagram. A more specific diagram may also be appropriate for a narrowly scoped functionality.
• The instructor suggests 10 use cases as a target, but fewer can be acceptable if they are well chosen and modeled properly.
• Identify two include relationships and one extend relationship where appropriate. Do not add relationships arbitrarily just to meet a count.
• Specify at least two use cases, preferably important ones for the selected functionality. Specify more if needed to practice and understand the technique.

Carry forward the domain model

Revise the earlier domain model using the instructors’ corrections. The lecturer describes it as optional in one part of the explanation, while elsewhere presenting it as part of the integrated work.

Add TP3 analysis and design artifacts

The TP3 submission should include:

• Analysis class diagram
• Analysis packages and package diagram, with an architectural description
• Collaboration diagrams
• Sequence diagrams for the specified use cases
• Design class diagram

The sequence and collaboration diagrams should correspond to the specified use cases and agree with the other diagrams. For example, objects and classes in a sequence diagram should be identifiable in the class diagram. Source-code generation artifacts are not required.

Analysis Classes

The analysis class diagram should show class responsibilities, attributes, and relationships—not methods. Identify each class by type:

• Entity classes represent concepts in the problem domain and information the system needs to maintain, such as pets, owners, or clients in a veterinary system.
• Interface classes support interaction between an actor and the system, such as a data-entry screen or a screen that displays a pet’s medical history.
• Control classes coordinate a use case’s execution, including checks, calculations, and the handling of temporary or intermediate data.

Attributes should suit each class and its role. Entity attributes typically come from the domain model; interface attributes relate to information entered or shown; and control attributes may hold values calculated or accumulated while a use case runs.

Identifying class types helps ensure that students are doing analysis rather than jumping straight to an implementation-focused design.

Analysis Packages

Analysis packages organize artifacts into manageable groups. A practical way to identify them is to group related use cases and classes by functionality—for example, sales management, order management, or customer management. The package structure should reflect the system’s use cases and class diagram.

Sequence and Collaboration Diagrams

A sequence diagram shows messages exchanged between objects in time order. It models the interaction for a particular use case; a use-case diagram does not show that sequence.

When creating a sequence diagram:

• Place the participating actor and objects across the top.
• Put the actor or object that initiates the interaction on the left.
• Show each participant’s timeline vertically.
• Represent messages between participants in temporal order.
• Use objects corresponding to the identified interface, control, and entity classes.
• Base the diagram on a use case that has been specified, and keep its messages and data consistent with the class diagram.

Collaboration diagrams are also requested. Although the lecturer notes that they are not required in the latest UML version, they are encouraged as a way to practice another view of object interaction.

Learning and Quality Advice

The lecturer encourages students to track what they understand, what remains unclear, and what they need to practice. UML modeling is a skill developed through repeated practice, not just by memorizing definitions.

Students should review instructor feedback, revise earlier work, and check that the submission forms one coherent whole rather than a collection of disconnected diagrams. The lecturer also encourages reflection on professional integrity and on the habits that help or hinder learning.

The stated TP3 deadline is October 19, described in the recording as the following Monday.

Speakers and Sources

• Ana Carolina Ferreira — lecturer presenting the TP3 guidance.
• Dr. Roxana Martínez — identified by Ferreira as the course’s lead professor; she is mentioned but does not speak in the subtitles.
• Referenced instructional material: a recording of a previous meeting and examples discussed in class, including a veterinary-system example and a disc-registration sequence-diagram example.