Software Engineering
Q What is Cohesion? What is Coupling? (In Class Design)
The Cohesion of a component is a measure of the closeness of the relationship between its components. Coupling is a measure of the independence of components. Coupling is related to Cohesion. It is an indication of the strength of interconnections between the components in a design.
Functional Requirements definition
- Statements of services the system should provide & how the system should react to particular inputs.
Non-Functional Requirements definition
- constraints on the services or functions offered by the system such as timing constraints, constraints on the development process, standards, etc.
Q What do 'Collaboration Diagrams *Also Communication Diagrams' do?
A 'Collaboration or Communication diagram' in the Unified Modeling Language (UML) 2.0, is a simplified version of the UML 1.x collaboration diagram.[1] UML has four types of interaction diagrams: Sequence diagram Communication diagram Interaction overview diagram Timing diagram A Communication diagram models the interactions between objects or parts in terms of sequenced messages. Communication diagrams represent a combination of information taken from Class, Sequence, and Use Case Diagrams describing both the static structure and dynamic behavior of a system. However, communication diagrams use the free-form arrangement of objects and links as used in Object diagrams. In order to maintain the ordering of messages in such a free-form diagram, messages are labeled with a chronological number and placed near the link the message is sent over. Reading a communication diagram involves starting at message 1.0, and following the messages from object to object. Communication diagrams show a lot of the same information as sequence diagrams, but because of how the information is presented, some of it is easier to find in one diagram than the other. Communication diagrams show which elements each one interacts with better, but sequence diagrams show the order in which the interactions take place more clearly.
Q What do 'Sequence Diagrams' do?
A Sequence diagram is an interaction diagram that shows how processes operate with one another and what is their order. It is a construct of a Message Sequence Chart. A sequence diagram shows object interactions arranged in time sequence. It depicts the objects and classes involved in the scenario and the sequence of messages exchanged between the objects needed to carry out the functionality of the scenario. Sequence diagrams are typically associated with use case realizations in the Logical View of the system under development. Sequence diagrams are sometimes called event diagrams or event scenarios. A sequence diagram shows, as parallel vertical lines (lifelines), different processes or objects that live simultaneously, and, as horizontal arrows, the messages exchanged between them, in the order in which they occur. This allows the specification of simple runtime scenarios in a graphical manner. Sequence Diagrams: A sequence diagram is a form of interaction diagram which shows objects as lifelines running down the page, with their interactions over time represented as messages drawn as arrows from the source lifeline to the target lifeline. Sequence diagrams are good at showing which objects communicate with which other objects; and what messages trigger those communications. Sequence diagrams are not intended for showing complex procedural logic.
Q Component diagram - give an example of a component mismatch and what does this mean?
A major emphasis in software development is placed on identifying and reconciling architectural and design mismatches. These mismatches happen during software development on two levels: while composing system components (e.g. COTS or in-house developed) and while reconciling view perspectives. Composing components into a system and `composing' views (e.g. diagrams) into a system model are often seen as being somewhat distinct aspects of software development. However, as this paper shows, their approaches in detecting mismatches complement each other very well. In both cases, the composition process may result in mismatches that are caused by clashes between development artefacts. Our component-based integration approach is more high-level and can be used early on for risk assessment while little information is available. Model-based integration, on the other hand needs more information to start with but is more precise and can handle large amounts of redundant information.
Q What are the problems associated with Requirements Specification
Ambiguity, over-flexibility, lack of modularisation, etc.
Q What are the functional requirements for Facebook / Socialbook?
Examples: Functional -All non-banned users will be able to create and manage (including security settings) a profile to display information to other users viewing the profile. -Users should be able to send messages and share photos to/with other users which can be either private (1 to 1) or public (group). -Users should be able to browse listing by searching for a user and if the privacy setting for the viewed user allow view that users posts. -Users should be able to post reviews of content on the site and other content. The users should also be able to rate the content. -Users should be able to place orders for listed items and pay for orders via a card system. -Game Companies are able to produce games and link them to the system/site. These companies can also charge for their games using the payment system. Users are able to play these games. -Businesses should be able to advertise deals and products on the site. Businesses should also be able to update their advertisements and managed any products they have for sale on the site.
Q What are the Non-functional requirements for Facebook / Socialbook?
Examples: Non-Functional -The system automatically moderates any content posted by users. Should any content fail the automatic check it is passed to a manual moderator for review. The moderator can then place restrictions on the user if the message fails the manual moderation. -The payment method(s) must be secure. -The system + database must be secure. -The system should display content the user is most likely to be interested in at the top of their page. -The system should have anti addiction policies to prevent overuse. -The system should be able to remember the users payment information for future purchases. -The system should target advertisements. -The system should support multiple platforms. -The service should be available 24/7 -The system should respond in real time (no more than a delay of 3 seconds). -The system + database must be maintainable....
Q What does a 'Use Case' model do?
I often use this to remember the two: My use case: I am going to the city. includes -> drive the car extends -> fill the petrol "Fill the petrol" may not be required at all times, but may optionally be required based on the amount of petrol left in the car. "Drive the car" is a prerequisite hence I am including. A Use Case Model describes the proposed functionality of a new system. A Use Case represents a discrete unit of interaction between a user (human or machine) and the system. This interaction is a single unit of meaningful work, such as Create Account or View Account Details. Each Use Case describes the functionality to be built in the proposed system, which can include another Use Case's functionality or extend another Use Case with its own behavior. A use case diagram at its simplest is a representation of a user's interaction with the system that shows the relationship between the user and the different use cases in which the user is involved. A use case diagram can identify the different types of users of a system and the different use cases and will often be accompanied by other types of diagrams as well.
Q What does synchronous and asynchronous mean in Sequence Diagrams?
If the lifeline is that of an object, it demonstrates a role. Leaving the instance name blank can represent anonymous and unnamed instances. Messages, written with horizontal arrows with the message name written above them, display interaction. Solid arrow heads represent synchronous calls, open arrow heads represent asynchronous messages, and dashed lines represent reply messages. If a caller sends a synchronous message, it must wait until the message is done, such as invoking a subroutine. If a caller sends an asynchronous message, it can continue processing and doesn't have to wait for a response. Asynchronous calls are present in multithreaded applications and in message-oriented middleware. Activation boxes, or method-call boxes, are opaque rectangles drawn on top of lifelines to represent that processes are being performed in response to the message (ExecutionSpecifications in UML). Synchronous message A synchronous message is used when the sender waits until the receiver has finished processing the message, only then does the caller continue (i.e. a blocking call). Most method calls in object-oriented programming languages are synchronous. A closed and filled arrowhead signifies that the message is sent synchronously. The white rectangles on a lifeline are called activations and indicate that an object is responding to a message. It starts when the message is received and ends when the object is done handling the message. When messages are used to represent method calls, each activation corresponds to the period during which an activation record for its call is present on the call stack. If you want to show that the receiver has finished processing the message and returns control to the sender, draw a dashed arrow from receiver to sender. Optionally, a value that the receiver returns to the sender can be placed near the return arrow. If you want your diagrams to be easy to read, only show the return arrow if a value is returned. Otherwise, hide it. Asynchronous messages With an asynchronous message, the sender does not wait for the receiver to finish processing the message, it continues immediately. Messages sent to a receiver in another process or calls that start a new thread are examples of asynchronous messages. An open arrowhead is used to indicate that a message is sent asynchrously. A small note on the use of asynchronous messages : once the message is received, both sender and receiver are working simultaneously. However, showing two simultaneous flows of control on one diagram is difficult. Usually authors only show one of them, or show one after the other.
Q What does an 'Activity Diagram' do?
In UML, an activity diagram is used to display the sequence of activities. Activity diagrams show the workflow from a start point to the finish point detailing the many decision paths that exist in the progression of events contained in the activity. They may be used to detail situations where parallel processing may occur in the execution of some activities. Activity diagrams are useful for business modelling where they are used for detailing the processes involved in business activities. Activity diagram is another important diagram in UML to describe dynamic aspects of the system. Activity diagram is basically a flow chart to represent the flow from one activity to another activity. The activity can be described as an operation of the system. So the control flow is drawn from one operation to another. This flow can be sequential, branched or concurrent. Activity diagrams deals with all type of flow control by using different elements like fork, join etc. Purpose: The basic purposes of activity diagrams are similar to other four diagrams. It captures the dynamic behaviour of the system. Other four diagrams are used to show the message flow from one object to another but activity diagram is used to show message flow from one activity to another. Activity is a particular operation of the system. Activity diagrams are not only used for visualizing dynamic nature of a system but they are also used to construct the executable system by using forward and reverse engineering techniques. The only missing thing in activity diagram is the message part. It does not show any message flow from one activity to another. Activity diagram is some time considered as the flow chart. Although the diagrams looks like a flow chart but it is not. It shows different flow like parallel, branched, concurrent and single. So the purposes can be described as: Draw the activity flow of a system. Describe the sequence from one activity to another. Describe the parallel, branched and concurrent flow of the system.
What do Class Diagrams do?
In software engineering, a class diagram in the Unified Modeling Language (UML) is a type of static structure diagram that describes the structure of a system by showing the system's classes, their attributes, operations (or methods), and the relationships among objects. The class diagram is a static diagram. It represents the static view of an application. Class diagram is not only used for visualizing, describing and documenting different aspects of a system but also for constructing executable code of the software application. The class diagram describes the attributes and operations of a class and also the constraints imposed on the system. The class diagrams are widely used in the modelling of object oriented systems because they are the only UML diagrams which can be mapped directly with object oriented languages. The class diagram shows a collection of classes, interfaces, associations, collaborations and constraints. It is also known as a structural diagram. Purpose: The purpose of the class diagram is to model the static view of an application. The class diagrams are the only diagrams which can be directly mapped with object oriented languages and thus widely used at the time of construction. The UML diagrams like activity diagram, sequence diagram can only give the sequence flow of the application but class diagram is a bit different. So it is the most popular UML diagram in the coder community. So the purpose of the class diagram can be summarized as: Analysis and design of the static view of an application. Describe responsibilities of a system. Base for component and deployment diagrams. Forward and reverse engineering.
Q What is the MoSCoW Criteria?
MoSCoW is a technique used in management, business analysis, and software development to reach a common understanding with stakeholders on the importance they place on the delivery of each requirement.
Q Describe how the RUP Model works?
Short for Rational Unified Process, a software development methodology from Rational. Based on UML, RUP organizes the development of software into four phases, each consisting of one or more executable iterations of the software at that stage of development. inception-- In this stage, the projects business case is stated and the team decides if the project is worth doing or if it is even possible. It is important to the process to first formulate the scope of the project and also determine what resources will be needed. elaboration -- In this stage, the developers take a closer look at the project to determine its architectural foundation and to evaluate the architecture in relation to the project. This stage is important to the RUP because it is here that developers analyze the risks associated with changing the scope of the project or adding new technologies along the way. construction-- In this stage, the development of the project is completed. The application design is finished and the source code is written. It is in this stage that the software is tested to determine if the project has met its goal laid out in the inception phase. transition -- In this stage, any fine-tuning is performed. Any final adjustments can be based on user feedback, usability or installation issues. RUP is similar in concept to Extreme Programming in that only what is useful and required is produced and the development plan is updated throughout the process. Both methods seek to develop a system of best practices in software development.
Q Identify requirements in the Moscow Criteria?
The MoSCoW method can help. MoSCoW stands for must, should, could and would: M - Must have this requirement to meet the business needs. S - Should have this requirement if possible, but project success does not rely on it. C - Could have this requirement if it does not affect anything else in the project. W - Would like to have this requirement later, but it won't be delivered this time. Often used in requirements prioritisation and as a language for specifying requirements o M: Must have- mandatory requirements that are fundamental to the system o S: Should have - important requirements that could be omitted o C: Could have - optional requirements o W: Want to have - these requirements really can wait (i.e. bells and whistles)
Q What is the 'Waterfall Model'?
The waterfall model is a popular version of the systems development life cycle model for software engineering. Often considered the classic approach to the systems development life cycle, the waterfall model describes a development method that is linear and sequential. Waterfall development has distinct goals for each phase of development. Imagine a waterfall on the cliff of a steep mountain. Once the water has flowed over the edge of the cliff and has begun its journey down the side of the mountain, it cannot turn back. It is the same with waterfall development. Once a phase of development is completed, the development proceeds to the next phase and there is no turning back.
Q When should you use the Waterfall Model? (Speak about the advantages and disadvantages of the Waterfall Model.)
When to use the waterfall model: This model is used only when the requirements are very well known, clear and fixed. Product definition is stable. Technology is understood. There are no ambiguous requirements Ample resources with required expertise are available freely The project is short. Advantages of waterfall model: This model is simple and easy to understand and use. It is easy to manage due to the rigidity of the model - each phase has specific deliverables and a review process. In this model phases are processed and completed one at a time. Phases do not overlap. Waterfall model works well for smaller projects where requirements are very well understood. Disadvantages of waterfall model: Once an application is in the testing stage, it is very difficult to go back and change something that was not well-thought out in the concept stage. No working software is produced until late during the life cycle. High amounts of risk and uncertainty. Not a good model for complex and object-oriented projects. Poor model for long and ongoing projects. Not suitable for the projects where requirements are at a moderate to high risk of changing.
Examples of Functional Requirements
o The library system shall provide a facility for identifying the identity of a library user o The library system shall provide a reminder when the book is overdue
Non-functional Requirements description
o These define system properties and constraints o e.g. reliability, security, availability, etc. response time o storage requirements. Constraints are I/O device capability, distribution paradigm etc. o Use of particular systems, programming language or development methods etc. o Non-functional requirements may be more critical than functional requirements. If these are not met, the system is useless. [A constraint on how the functional requirements may be implemented] • The library system shall authenticate a library customer in five seconds or less • The library system shall be available 24/7 The library system shall abide to iso standards
Q -what is the purpose of a State diagram? -give an example of a State diagram? -explain parallel states?
• Also known as statecharts (invented by David Harel) • Used primarily to model state of an object • A class has at most one state machine diagram - Models how an object's reaction to a message depends on its state Objects of the same class may therefore receive the same message, but respond differently. State Machine Diagrams A state machine diagram models the behaviour of a single object, specifying the sequence of events that an object goes through during its lifetime in response to events. The state diagram in the Unified Modeling Language is essentially a Harel statechart with standardized notation, which can describe many systems, from computer programs to business processes. In UML 2 the name has been changed to State Machine Diagram.
Q What do Component diagrams do?
• The component diagram's main purpose is to show the structural relationships between the components of a system • Component diagrams offer architects a natural format to begin modeling a solution • Component diagrams allow an architect to verify that a system's required functionality is being implemented by components • Helps to reason about non-functionalities Developers find the component diagram useful because it provides them with a high-level, architectural view of the system that they will be building Component Diagrams Component diagrams illustrate the pieces of software, embedded controllers, etc., that will make up a system. A component diagram has a higher level of abstraction than a Class Diagram - usually a component is implemented by one or more classes (or objects) at runtime. They are building blocks so a component can eventually encompass a large portion of a system. In the Unified Modeling Language, a component diagram depicts how components are wired together to form larger components and or software systems. They are used to illustrate the structure of arbitrarily complex systems. Overview: Component diagrams are different in terms of nature and behaviour. Component diagrams are used to model physical aspects of a system. Now the question is what are these physical aspects? Physical aspects are the elements like executables, libraries, files, documents etc which resides in a node. So component diagrams are used to visualize the organization and relationships among components in a system. These diagrams are also used to make executable systems. Purpose: Component diagram is a special kind of diagram in UML. The purpose is also different from all other diagrams discussed so far. It does not describe the functionality of the system but it describes the components used to make those functionalities. So from that point component diagrams are used to visualize the physical components in a system. These components are libraries, packages, files etc. Component diagrams can also be described as a static implementation view of a system. Static implementation represents the organization of the components at a particular moment. A single component diagram cannot represent the entire system but a collection of diagrams are used to represent the whole. So the purpose of the component diagram can be summarized as: Visualize the components of a system. Construct executables by using forward and reverse engineering. Describe the organization and relationships of the components.
